In existing network environments, managing a client (e.g., a server, service, application program, or operating system component) involves managing configuration data stored on the client. In one example, a large number of different servers often host a variety of different services (e.g., web services, soap services, and/or operating system services). A server hosting a particular service usually stores thereon configuration data (e.g., software settings, operational parameters, service uniform resource locators (URLs), data retention policies, and site properties). Such configuration data defines an operation of the server in hosting the particular service. For example, the configuration data may determine an operational state of the server (i.e., whether the server is executing a service) as well as when and how a service is executed on the server.
As the network environment grows increasingly larger, managing or organizing a relationship among different clients and/or configuration data also becomes an increasingly complex task. For example, there may be a number of service classes, wherein a service class defines a set of services executable on a particular server (e.g., registration service and member center service may be part of the same service class). A group of servers may also be defined to execute one or more services belonging to a particular service class. Accordingly, servers belonging to this group of servers may share certain configuration data and other settings in order to provide a uniform and integrated service. As can be seen, managing configuration data (e.g., changing/overriding, adding/removing, and viewing the configuration data) across different server groups or service classes can be a challenging task.
In prior systems and methods, managing configuration data involves manually managing the configuration data of a particular client. For example, in prior systems and methods, an administrator would change configuration data by manually identifying one or more clients affected by a change in the configuration data and then manually updating the configuration data in the identified clients one by one. Such prior systems and methods create substantial operational problems for network administrators. First, a large number of files, data access methods, and tools are frequently needed to manipulate configuration data across different clients. This results in a difficulty to track, schedule, and execute configuration data changes, and requires a great understanding of the network environment in order to identify the affected clients. Second, the prior systems and methods do not have a simple way to select a large group of clients, schedule a one-time or recurring configuration data change, and then uniformly apply the configuration data change to the large group of clients. In particular, managing clients and performing configuration data changes to a large group of clients require many manual steps. Third, the prior systems and methods do not attempt to keep track of an operation of a particular client. Therefore, changing configuration data in the previous systems often involves manually applying configuration data changes to a large group of clients, when in reality a smaller group of clients should have been affected by the changes. This creates inconsistency in managing configuration data and further wastes valuable network resources.
Another disadvantage of the prior systems and methods is the difficulty in keeping track of a configuration state of a particular client. Specifically, there lacks a system that identifies the clients in a network environment, their configuration states, and their operations. Additionally, the prior systems and methods do not provide consistent data versioning for configuration data and thus cannot identify and record a particular configuration state as a “complete” configuration state in order to support rollback or roll-forward of client configuration state. For example, when a change in configuration data adversely affects the behavior of a client, it is difficult and expensive to change the configuration state of the client to a previous “complete” configuration state. Adding to the difficulty to rollback or roll-forward a configuration state is a lack of support for auditing a sequence of changes to configuration data. This further results in inabilities to track changes that cause system instability, to monitor client performance, and to prevent conflicting configuration data changes.
Yet another disadvantage of the prior systems and methods is the ineffectiveness in controlling access to configuration data of a particular client. The prior systems and methods do not have an effective authorization system for controlling access to configuration data. Usually, an individual either is allowed to access and change configuration data or is denied access to the configuration data. As such, the prior systems and methods cannot provide flexibility in allowing an individual to change/override, add/remove, and view configuration data of a client or group of clients.
The prior systems and methods also lack knowledge of the rotation status of the servers/services in the system. Without knowing such rotation status, more than expected servers may be taken out of rotation for deployment and/or maintenance, which causes reduction of expected service availability. Further, the prior systems and methods lack a cache system that is directly available to individual clients. This means that in the previous systems and methods, some clients may be forced to build different sub-caches to store configuration data in different formats compatible with the sub-caches. This further causes waste of network and local system resources, inconsistent storage formats, and inefficiency in managing configuration data. In addition, the prior systems and methods lack a uniform centralized storage model and access interface. This causes additional development cost for designing, implementing, testing, and deploying the additional storage model and access interface.
Accordingly, a solution that seamlessly manages configuration data across different clients is desired to address one or more of these and other disadvantages.